Both Readers : Read a line back, and write one that runs right to left the right way round - #988
Open
dkulyk wants to merge 1 commit into
Open
Both Readers : Read a line back, and write one that runs right to left the right way round#988dkulyk wants to merge 1 commit into
dkulyk wants to merge 1 commit into
Conversation
dkulyk
force-pushed
the
fix/reader-line
branch
4 times, most recently
from
September 8, 2026 08:54
ddb2db2 to
6761941
Compare
…t the right way round Both Writers write a `Line` and neither Reader read one, so a deck that was loaded and saved again lost every line it had. `loadSlideShapes()` in the PowerPoint2007 Reader switches on the tag name and had no `p:cxnSp` arm; the ODPresentation Reader walks `draw:frame` only, and a `draw:line` is a shape of the page in its own right rather than the content of a frame. Measuring the round trip turned up a second defect, in the Writer, which had to go with it. An OOXML extent cannot be negative, so a line whose end is behind its start is written from the other end with `flipH` or `flipV` saying which axis it is mirrored on. `writeShapeLine()` wrote `flipV` for a line that runs right to left, and nothing at all for one that runs up and to the left, so both arrived mirrored in PowerPoint with no reader involved. `PptSlidesTest::testLine` created all four lines but asserted only that some `a:xfrm` carried a `flipV`, which the line running up and to the right satisfies on its own. The ODPresentation Writer needed nothing: ODF says a line by the two points it runs between, so a negative width is an `svg:x2` smaller than the `svg:x1`.
dkulyk
force-pushed
the
fix/reader-line
branch
from
September 8, 2026 18:53
6761941 to
8e5c70a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Both Writers write a
Lineand neither Reader read one back, so a deck that was loaded and saved again lost every line it had.Reader/PowerPoint2007::loadSlideShapes()switches on the tag name and had nop:cxnSparm;Reader/ODPresentation::loadSlide()walkeddraw:frameonly, and adraw:lineis a shape of the page rather than the content of a frame.Measuring the round trip turned up a second defect, in the Writer, which had to go with it. An OOXML extent cannot be negative, so a line whose end is behind its start is written from the other end with
flipH/flipVsaying which axis it is mirrored on.writeShapeLine()wroteflipVfor a line that runs right to left, and nothing at all for one that runs up and to the left:flipVflipVflipVflipHflipHandflipVSo a line drawn right to left arrived mirrored in PowerPoint, with no reader involved.
PptSlidesTest::testLinecreated all four lines but asserted only that somea:xfrmcarried aflipV, which the second case satisfies on its own, so nothing caught it. That test now says which of the three forms it expects, and the two readers each round-trip a line in all four directions.The ODPresentation Writer needed nothing: ODF says a line by the two points it runs between, so a negative width is simply an
svg:x2smaller than thesvg:x1.Fixes #987
Checklist:
composer run-script check --timeout=0and no errors were reported